As the use of security routines to verify the integrity of operating systems and/or of application routines executed within the operating environments of operating systems has become commonplace, those security routines have themselves become the targets of malicious software (e.g., such malware as viruses, worms, etc.). Indeed, malicious software is often written with a presumption having been made that there will be a security routine of some type that must first be defeated before whatever malicious actions that are intended against the operating system and/or application routines are able to be performed (e.g., logging keystrokes, stealing data, sending unsolicited emails to other processing devices, etc.).
As a result, various approaches have been proposed for addressing efforts by malicious software to attack such security routines. Such proposals have included creating a second operating environment that is entirely separate from the operating environment in which an operating system and/or application routines are executed through the provision of a separate processor component and/or storage. Unfortunately, the wide range of processor-intensive functions that may be performed by such security routines may require that such a separate processor component have considerable processing capabilities and/or that such a separate storage have considerable capacity. Stated differently, the second operating environment may require processing and/or storage resources that might rival those of the operating environment in which operating system and/or the application routines are executed, and such duplication of processing and/or storage resources to create such a second operating environment may be deemed cost-prohibitive and/or inefficient in terms of electric power consumption.